Transparent Interconnect of Lots of Links (TRILL) is an IETF standard implemented in RBridges. TRILL provides an architecture of Layer 2 control and forwarding that enjoys major benefits such as pair-wise optimal forwarding, loop mitigation, multipathing and provisioning tree. TRILL supports incremental deployment and interoperation with classical Ethernet (CE) through mechanisms such as adjacencies over shared media, designated RBridge (DRB) election and appointed forwarder (AF) assignment. RBridges on a network run a link state protocol such as Intermediate System-to-Intermediate System (IS-IS), for example, to broadcast connectivity to other RBridges on the network. Using the link state protocol, the RBridges determine connectivity between the RBridges. For example, the RBridges obtain information needed to calculate pair-wise optimal paths for unicast and/or distribution trees for multicast/broadcast using the link state protocol.
Providing service insertion and clustering in a TRILL network has a number of challenges. For example, automatic discovery of service nodes in a TRILL network can present challenges. Additionally, upon inserting a new service node into a service cluster, existing traffic flows should not be disrupted by redistribution of load-balancing hash values. In particular, a reverse flow should be serviced by the same service node(s) that serviced the forward flow. This is referred to as “stickiness.”
Providing a control plane for implementing service insertion, clustering and chaining can also present challenges. A service cluster can include multiple service types that are processed sequentially in a service chain, and each of the service types can be hosted on one or more service nodes for load-sharing. A TRILL network can include a plurality of service clusters, and each service node can belong to one or more of the service clusters. The control plane should direct new traffic flows dynamically to service node(s) based on current usage of the service nodes in the service cluster for efficient use of the capacity of the service cluster. Accordingly, providing a control plane adds another layer of complexity. Additionally, providing a flexible, scalable solution for any topology of client-facing packet-forwarding devices, server-facing packet-forwarding devices and service appliances by leveraging the combined resources within a TRILL network presents challenges. For example, provisioning on-demand service clusters by leveraging combined resources of a TRILL network (e.g., integrated services modules, connected service appliances, etc.) in the TRILL network without the overhead of management complexity, which typically involves globally administered VLAN switching configurations in packet-forwarding devices, service modules on a per chassis basis and associated service appliances, can be challenging. This may be of paramount importance in enterprise campus and data center deployments, where a basic challenge is that each packet-forwarding device has no notion of the available service types or the total service bandwidth in the TRILL network.